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Discussion of Sufficiency of the 37 C.F.R. § 1.131 Declaration 

Applicant believes that all claim rejections are overcome by removing Giorgio as a 
reference, since the remaining independent claims, Claims 1, 7 and 14, are rejected as anticipated 
or obvious over Giorgio. 

Claim 1 was rejected because the Examiner stated that Applicant's Exhibits A-G 
provided no description "[of] the remote interface, executing the command on the micro 
controller, and sending a retrieve or update system status signal from the micro controller to the 
first computer thereby retrieving or updating system status." Applicant respectfully disagrees and 
maintains that the Declaration under 37 C.F.R. § 131 to Overcome Giorgio (April 13, 1999) is 
sufficient to overcome the Examiner's rejections of the independent claims. 
As stated in the M.P.E.P. §715.07: 

"The essential thing to be shown under 37 FR 1.131 is priority of 
invention. This may be done by any satisfactory evidence of the fact. . . However, 
when reviewing a 37 CFR 1.131 affidavit or declaration, the examiner must 
consider all of the evidence presented in its entirety, including the affidavits or 
declarations and all accompanying exhibits, records and "notes." An 
accompanying exhibit need not support all claimed limitations, provided that any 
missing limitation is supported by the declaration itself. Ex Parte Ovshinsky, 10 
USPQ2d 1075 (Bd. Pat. App. & Inter. 1989)." 

Applicants were employed by a server developer and computer manufacturer and as is 
customary in the computer industry, documentation was written at various times during the 
development cycle. Documentary evidence at computer companies is typically in the form of 
white papers (concept), architecture documents, system and subsystem specifications, and 
schematic diagrams. An examination of the exhibits previously submitted in support of the 
Declaration shows that these are precisely the types of documents that one would expect to see 
arise from the engineering development of a computer. Table 1 lists the previously submitted 
exhibits. 
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TABLE 1 





DUCUMIldM 1 INAMIL 




A 


Raptor System: A Bird's Eye View 


Server (first computer) system overview 
document (white paper) 


B 


Raptor Wire Service Architecture, Version 
1.0 


Document describing architecture of the 
maintenance and control 
microcontrollers 


C 


Schematic of Raptor Remote Board, 
Revision 01 


ocnematic (blueprint j oi remote 
interface 


D 


Remote Interface Board Specification 


Document describing architecture of 
remote interface 


E 


E-mail hardcopy 


Shows that aspects of the invention 
conunueci 10 dc ueveiopcu 


F 


Raptor Wire Service Architecture, Version 
1.3 


New version of architecture document 


G 


Schematic of P6 Mother Board 


Schematic (blueprint) of board 
containing several of the 
microcontrollers for the server 


H 


Schematic of Raptor Remote Board, 
Revision 54 


Updated schematic for the remote 
interface 



Exhibit A, "Raptor System, A Bird's Eye View," p. 9 (Nov. 2, 1995) outlines the various 
systems conditions Raptor ( the first computer) was proposed to monitor. 

Exhibit B, "Raptor Wire Service Architecture," p. 7-8 (January 23, 1996), describes the 
limitation of "sending a command for remotely retrieving or updating system status." Remotely 
retrieving or updating system status refers to the ability of a remotely located computer (second 
computer) to issue a command to the first computer via the remote interface link. These 
commands are either "Read" or "Write Event Message Requests." The "Read Event Message" 
commands the monitored computer (hereinafter "first computer") to allow the second computer 
to read the status associated with the microcontroller in the first computer. The data is displayed 
on the second computer. Thus, the second computer has sent a command to retrieve data about 
the first computer's system status. 

Similarly, a "Write Event Message" from the second computer commands the first 
computer to allow the second computer to write (update) a new parameter, such as a fan speed 
threshold, to the first computer also via the microcontroller bus. Thus, the second computer sends 
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a command to update the first computer's system status. The architecture of the message requests 
describes whether the request is a "read" or a "write" message request and identifies the type of 
event contained within the message. Possible events covered by these messages are CPU status 
changes, power status changes, canister status changes, and fan status changes. Thus, system 
status of the first computer can be remotely retrieved or updated by an interface to a remote 
second computer using either a "read" or "write" event message. 

Further, Claim 1 was rejected because the evidence, "as a whole contained] no sketches, 
blueprints, notes records of meetings.... etc." See Office Action, para. 4. Applicant respectfully 
disagrees. Exhibit F, p. 1 (October 3, 1996), is a block circuit diagram describing the Wire 
Service Hardware configuration. The Wire Service Hardware comprises a plurality of 
maintenance and control microcontrollers connected by a microcontroller bus (here called the 
Wire Service Bus). A block circuit diagram is a blueprint for an electrical circuit as it faithfully 
describes the components and connections of the circuit. The diagram illustrates how the System 
Recorder, Chassis Controller, CPU A Controller and CPU B Controller, the System Interface 
Controller and Remote Interface Controller directly or indirectly tie into the Wire Service Bus. 

Exhibit F, p. 36, provides a description of the remote interface in the section entitled 
"Wire Service Remote Interface Serial Protocol." The interface is used to communicate 
commands and other messages across a serial link from a remote interface controller connected 
to the first computer to a remote management processor in the second computer. The remote 
interface controller encapsulates commands and messages in a transmission envelope for error 
free communications and link security. There are two classes of messages. The first class 
includes "Requests" sent by remote management systems (the second computer) to the remote 
interface and received at the first controller of the first computer. The second class includes 
"Responses" that are returned to the second computer through the remote interface. This 
provides the basis for remotely retrieving or updating system status. 

Further, the Examiner rejected Claim 1 because the Exhibits did not provide a description 
of "executing the command on a microcontroller." Applicant respectfully disagrees. Exhibit F, 
p. 1 (October 3, 1996), is a block circuit diagram showing the Wire Service Hardware 
configuration. CPU A Controller and CPU B Controller are microcontrollers that may receive 
the retrieval or update system status commands in the first computer. The block diagram shows 
the input and output signal paths as well as the connection to the wire service bus. An incoming 
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command from the Remote Interface moving along the Wire Service Bus is monitored by CPU A 
Controller and CPU B Controller. A properly encoded command is therefore monitored by 
microcontroller CPU A or B, and if appropriate, executed. Thus, the Exhibit is sufficient to 
illustrate executing the command on a microcontroller in the first computer. 

Further, the Examiner rejected Claim 1 because the Exhibits did not provide a description 
of "sending a retrieve or update system status signal from the microcontroller to the first 
computer thereby retrieving or updating the system status." Applicant respectfully disagrees. 
Exhibit F, p. 1 (October 3, 1996), is a block circuit diagram describing the Wire Service 
Hardware configuration. Fan speed monitoring and control are representative of the system 
status. When a read event message to retrieve fan speed is detected by CPU A microcontroller, 
the microcontroller monitors the Fan Mux data output in the first computer. The fan speed data 
is retrieved by CPU A microcontroller and reported back to the second computer. Thus, a 
retrieve system status signal is sent from the microcontroller to the first computer thereby 
retrieving the system status (e.g., fan speed). The data signal path is explicitly illustrated on the 
block diagram. Thus, Exhibit F describes a method of sending a retrieve system status signal 
from the microcontroller to the first computer thereby retrieving the system status. 

Similarly, when a write update event message is received by CPU A microcontroller, the 
microcontroller may, for instance, activate a microcontroller output pin to transmit a signal along 
the Fan Speed Control path. This signal may change the fan speed, thereby modifying or 
updating the system state. The data signal path is explicitly shown on the block diagram. Thus, 
Exhibit F also describes a method of sending an update system status signal from the 
microcontroller to the first computer thereby updating the system status. 

In reference to Claim 7, Exhibits C and D address the claimed limitation of connecting a 
remote interface to a first computer and a second computer. Exhibit C, a schematic diagram of 
the remote interface board, illustrates the electrical connection to link the remote interface with a 
communications line to the second computer. Exhibit C also illustrates the SCL and SDA circuit 
paths connecting the remote interface board to the first computer via the RJ45 connector. 

Exhibit D, the Remote Interface Board Specification, Rev. 2, Figure 2, illustrates the 
physical embodiment of the connectors referred to in Exhibit C. Further, Exhibit D, Figure 3 
illustrates the enclosure design that physically connects the remote interface to the first and 
second computer. 
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Further, Exhibit F, p. 36 also addresses the claimed limitation of encapsulating the 
command in a communications protocol and transmitting the encapsulated command to the 
remote interface. The Wire Service Remote Serial protocol is used to communicate Wire Service 
commands and messages across a serial link from the second computer to the Wire Service 
Remote Interface. The protocol encapsulates Wire Service messages in a transmission envelope 
for error free communication and link security. 

In reference to Claim 14, Exhibits A, B, and F address the limitations not discussed 
above. Exhibit A, p. 8, describes a system to supervise and control specific functions of the first 
computer through a Control Diagnostic and Monitor (CDM) subsystem implemented by 
distributed CDM microprocessors connected to a I 2 C serial bus (CDM bus). The CDM can 
supervise and manage selected functions externally from a remote second computer via the CDM 
bus and communication lines. The computer environment is externally managed through the 
following process: a management operation to be performed by the first computer is selected at 
the second computer. The second computer communicates with the first computer by issuing a 
command or message instruction for a selected component at the first computer and a selected 
operation to be performed at the first computer. 

The first computer after receiving the command or message, communicates with the 
computer's microcontroller via its local CDM bus as described and illustrated in Exhibit F, p. 1. 
The first computer's microcontroller instructs the first computer to perform the command on the 
selected component. The first computer then executes the command and performs the selected 
operation on the selected component. Thus the first and second computers communicate with 
each other so that the first computer can perform the selected operation on the selected 
component. The CDM supervised and monitored functions of computer environmental 
parameters include ambient and exhaust temperatures, fan speed, speed control fan fault and 
overtemp indicators. 

The first and second computers communicate using the command and messaging 
techniques described in Exhibit B, p. 7-8, and Exhibit F, p. 36 (see above). 

Applicant respectfully submits that the rejection of independent Claims 1, 7 and 14 has 
been overcome. Since Claims 2-6, 8-13 and 15-32 are dependent on their corresponding 
independent claims, pursuant to 35 U.S.C. § 1 12, H4, they incorporate by reference all the 
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limitations of the claim to which they refer. Therefore, the rejection of the dependent Claims 
2-6, 8-13 and 15-32 has also been overcome. 



Applicant has endeavored to address the Examiner's concerns as expressed in the 
outstanding Office Action. In particular, the previously submitted Declaration and attached 
Exhibits are sufficient to remove Giorgio as a reference. In light of the above remarks, 
reconsideration and withdrawal of the outstanding rejections is respectfully requested. If the 
Examiner has any questions, which may be answered by telephone, the Examiner is invited to 
call the undersigned directly. 



Conclusion 



Respectfullv^Arnitted. 




KNOBBY/MARTENS, OLSON & BEAR, LLP 




By: M^-~^ 

John MY Carson 
Registration No. 34,303 
Attorney of Record 
620 Newport Center Drive 
Sixteenth Floor 
Newport Beach, CA 92660 
(619) 235-8550 
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